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Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

This Appeal Brief is submitted pursuant to the Notice of Appeal received in the U.S. 
Patent and Trademark Office on June 27, 2005, and in support of the appeal from the final 
rejection set forth in the Office Action mailed on April 15, 2005. The fee for filing a brief in 
support of an appeal is enclosed. 



I. REAL PARTY IN INTEREST 

The real party in interest is Cisco Technology, Inc., 170 West Tasman Drive, San Jose, 
California 95134-1706. Cisco Technology, Inc. is the Assignee of the entire right, title and 
interest in the subject application, by virtue of an Assignment recorded on August 18, 1999 at 
Reel 010170, Frames 0571-0580. 
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H. RELATED APPEALS AND INTERFERENCES 

Appellants, the undersigned Attorney, and Assignee are not aware of any related appeals 
or interferences which will directly affect or be directly affected by or have a bearing on the 
Board's decision in the pending appeal. 

m. STATUS OF CLAIMS 

Claims 1, 3, 5-9, 11-14, 18, 20-21, 23 and 27-34 have been finally rejected, and a copy 
appears in the Claims Appendix of this Brief. Claims 1-28 were amended in the Amendment 
filed on May 1, 2002. Claims 1, 3-5, 10, 18, 20-23 and 27-28 were amended in the Amendment 
filed on October 16, 2002. Claims 1, 3, 18, 20 and 27-28 were amended, claims 2, 4, 10, 15-17, 
19, 22 and 24-26 were canceled, and claims 29-34 were added in the Amendment filed on April 
11, 2003. Claims 1 1, 23 and 31 were amended in the Amendment filed on November 12, 2003. 
Claims 1,18, 27-29 and 31-32 were amended in the Amendment filed on March 11, 2004. 
Replies without claim amendments were filed on September 21, 2004 and February 17, 2005. 

IV. STATUS OF AMENDMENTS 

No amendments have been filed subsequent to the final rejection mailed April 15, 2005. 
Accordingly, the claim listing as presented in the amendment filed March 11, 2004 are the claims 
on appeal. A copy of the pending claims is listed in the Claims Appendix enclosed with this 
Appeal Brief. 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

Appellants' invention is directed to method and apparatus for prioritizing a network 
management request sent by a management station to a managed element. The network 
management request may be, for example, a Simple Network Management Protocol (SNMP) 
request which is a request to retrieve or modify objects (information stored in a predefined 
format, for example, text strings, counter values) stored in the managed element (for example, 
router, terminal server, switch). In accordance with the present approach, the network 
management request received by the managed element is assigned a priority value by the 
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managed element based on a user or source identifier in a network management message wrapper 
included in the request. The user identifier identifies the user of an application from which the 
request was sent. The source identifier identifies the source of an application from which the 
request was sent. The network management request is scheduled by the managed element 
dependent on the assigned priority value. 

Referring to FIG. 1, for example, management station 102 communicates over network 
100 with a managed element 104. FIG. 3 shows the format of an SNMP request 300 including a 
network management wrapper 302. FIG. 5 is a flow diagram of a method implemented in the 
managed element for prioritizing network management requests from network management 
applications. Referring to FIG. 5, using an agent 110 (FIG. 1) in the managed element 104, upon 
receiving an SNMP message 300, in step 502, the identification is extracted from the SNMP 
message wrapper 302. The identification in the message wrapper 302 may be a community 
identification, or a user identification or group identification, dependent on the version of SNMP 
implemented in the management station 102 and the managed element 104. 

In step 504, using the identification extracted from the SNMP message 300, the agent 
determines the priority of the SNMP message 300 from local control data (LCD) (FIGs. 4A, 4B) 
stored in the managed element. For example, if an SNMPv3 message is sent from user #2, the 
user identification in the SNMP message wrapper 302 is set to the identification for user #2. The 
agent 110 uses the identification for user #2 to determine the assigned priority from the local 
control data. 

In step 506, the agent 110 determines the priority of the SNMP message 300 dependent 
on the identification extracted from the LCD. In step 508, if the priority of the network 
management request in the SNMP message 300 is lower than the network management requests 
included in the SNMP messages 300 currently being processed, the SNMP message 300 may be 
added in order of priority to a pending queue, using any queuing algorithm known in the art. 

In step 508, if the priority of the SNMP message 300 is higher than the priority of SNMP 
messages 300 on an active task queue currently being processed, the agent 110 may determine 
that the SNMP message 300 is to be processed immediately. To immediately process the 
network management request included in the SNMP message 300, the SNMP message 300 may 
be added to the front of the active task queue, using any queuing algorithm known in the art. 
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FIG. 7 shows a portion of the contents of a configuration file for another embodiment in 
which network management requests are prioritized dependent on a network source address 
assigned to a network management request received by the managed element. The source 
address may be, for example, an IP address. The configuration file is stored in the managed 
element. Upon receiving a network management request from a network management 
application in a management station 102, the agent 1 10 in the managed element 104 extracts the 
source address from the network management request. The agent 110 uses the source address to 
obtain the priority associated with the source address from the configuration file. 

The network management request may be placed either at the front of the queue of active 
tasks or on a pending task queue, dependent on the priority of the network management request. 
Using the present approach, urgent network management requests can be processed before low 
priority network management requests and other tasks. 

VI. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1, 3, 5-9, 1 1-14, 18, 20, 21, 23 and 27-34 are unpatentable under 35 
U.S.C. 103(a) over Dulman (U.S. Patent No. 5,802,146) in view of Kjorsvik et al (U.S. Patent 
No. 5,748,190). 

VH. GROUPING OF CLAIMS 

Group I: Claims 1, 3, 5-9, 11-14, 18, 20, 21, 23 and 27-34 
The claims in Group I stand or fall together. 

VIE. ARGUMENT 

A. The Dulman patent ("Dulman") 

Dulman is directed to the use of SNMP messages for monitoring network elements of a 
public switched telephone network. An operations console communicates SNMP messages to 
and from network elements via a packet switched network. A network element includes an error 
monitoring system that collects and generates an error status report. The network element 
converts the error status report to SNMP messages and outputs the SNMP messages to the 
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operations console. The operations console displays the SNMP messages (objects) together with 
operational priority that is assigned by the console. 

Dulman discloses that the operating console can be kept up to date on the status of the 
network elements by regular polling of the network elements and that the operating console can 
initiate corrective measures by outputting SNMP objects to different network elements. 

B. The Kjorsvik et al patent fKiorsvik") 

Kjorsvik is directed to a presentation system for individual personal computers in a 
personal computer network. In lieu of displaying a screen saver on the screen of a personal 
computer that has been idle for a period of time, a repertoire of presentations stored in a system 
database located on a network server PC is provided for display on the personal computer. The 
repertoire of presentations takes the form of a series of successive slides or screen images. 

C. The Rejection under 35 U.S.C.S 103(a) 

Claims 1, 3, 5-9, 11-14, 18, 20-21, 23 and 27-34 (Group I herein) stand rejected under 35 
U.S.C. 103(a) as being unpatentable over Dulman in view of Kjorsvik. On pages 4-7 of the Final 
Office Action mailed April 15, 2005 ("Final Office Action"), the Examiner sets forth an 
argument combining the two references listed above. 

With respect to independent claims 1,18, 27-29 and 31-32, the Examiner indicates the 
view that Dulman discloses most of the claim limitations. In particular, the Examiner states that 
Dulman discloses assigning a priority value to the received network management request, citing 
column 4, lines 52-64; column 11, lines 34-57; and column 3, lines 23-32. The Examiner further 
states that Dulman discloses that the priority value is assigned by the managed element, referring 
to column 14, lines 58-67 and column 15, lines 1-28. Further, the Examiner points to the above- 
noted sections of Dulman to support the view that Dulman discloses scheduling the network 
management request, by the managed element dependent on the assigned priority value. 

The Final Office Action states that Dulman does not explicitly disclose a user identifier in 
a network management wrapper included in the request, where the user identifier is used to 
identify the user of an application from which the request was sent. The Examiner looks to 
Kjorsvik for this deficiency in Dulman, noting that Kjorsvik discloses: 
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[I]t is capable of displaying all the users in the network that have an installed 
messenger module. The individual users may be arranged into various groups 
according to the selection of the system operator, using the administration module 
26. Each user is identified by a unique network identification (ED). Hence, a 
command to view the network users in the database 24 is provided through the 
administration module 26. The user's IDs and the individual presentations are 
contained in the system database 24. (Kjorsvik: column 3, lines 18-29) 

The Examiner asserts that the foregoing teaches that the network computer has the capability to 

identify network users who communicate with it. With this combination, the Final Office Action 

states that it would have been obvious to a person having ordinary skill in the art at the time the 

invention was made to modify Dulman by incorporating user identifier in a network management 

wrapper included in the request, and that one of ordinary skill in the art would have been 

motivated to use such combination because it "would provide Dulman's system the identifying 

network user capability to provide network user identification for network communication in the 

network system." (Final Office Action: page 5) 

In a section of the Final Office Action entitled "Response to arguments" (pages 2-3), the 

Examiner responds to Applicants' Remarks filed on February 17, 2005, the Applicants' Remarks 

summarized by the Examiner as follows: 

Dulman (U.S. Patent No. 5,802,146) does not disclose or suggest, "prioritizing 
network management request sent by a management station to a managed element, 
prioritzing SNMP messages in the network element." Kjorsvik does not disclose 
or suggest, "user identifier in a network management wrapper." (Final Office 
Action: page 2) 

The Examiner's response states disagreement with Applicants' Remarks. In particular, 

the Examiner states that Dulman discloses the MOC 32 (operations console) is kept up to date on 

the status of the AIN nodes by regular polling of the respective SNMP agents. 

However, in cases where the AIN nodes may need to inform the MOC 32 of an 
extraordinary event without waiting to be polled, the SNMP agent 52 outputs a 
"trap." For example, when the IP 24 first comes on-line, the IP 24 may send a 
cold start trap to the MOC 32 in order to notify the MOC 32 of the existence of 
the IP 24. A trap tends to be a relatively simple structure, comprising one of six 
generic types, optional specific type information, the IP address of the originating 
agent and a reference to the MIB variable affected. (Dulman: column 13, lines 7- 
26) 
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The Examiner notes that since the network devices with SNMP agent in Dulman are 
"polled," a network management request is "received." Further, the Examiner states that the 
network devices (polled) and SNMP requests are prioritized, citing column 4, lines 52-64; 
column 11, lines 34-57; and column 3, lines 23-32 of Dulman for support, and concludes that 
Dulman discloses "prioritizing network management request sent by a management station to a 
managed element, prioritizing SNMP messages in a network element." 

With respect to Kjorsvik, the Examiner states the view that Kjorsvik discloses "user 
identifier in a network management wrapper " to provide SNMP command wrapper for user ID, 
again citing column 3, lines 18-29 of Kjorsvik for support. 

D. Appellants' Argument 

To establish a prima facie case for obviousness under 35 U.S.C. § 103(a), (1) there must 
be some suggestion or motivation to combine reference teachings; (2) there must be a reasonable 
expectation of success; (3) the references when combined must teach or suggest all the claim 
limitations. For the reasons discussed below, it is respectfully submitted that the Examiner has 
not established a prima facie case under 35 U.S.C. § 103 (a) for claims 1, 3, 5-9, 11-14, 18, 20, 
21, 23 and 27-34, and that therefore, claims 1, 3, 5-9, 1 1-14, 18, 20-21, 23, and 27-34 are 
allowable. 

Dulman is concerned with sending SNMP requests from an operations console (the MOC 
32) to network elements (e.g., IP 24), receiving SNMP objects relating to error reports from the 
network elements, assigning an operational priority to the received SNMP objects and displaying 
the operational priority of the received SNMP objects based on object relationships identified by 
a Management Information Base (MIB). 

Dulman does not teach or suggest a method for prioritizing a network management 
request sent by a management station to a managed element, nor does Dulman teach or suggest 
prioritizing SNMP messages received in a managed element. Dulman merely discusses that the 
operating console (element MOC 32 in Dulman) can be kept up to date on the status of the 
network element by regular polling of the network elements and that the operating console can 
initiate corrective measures by outputting SNMP objects to different network elements. There is 
no discussion of how SNMP objects received by the network element are prioritized by the 
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network element. Dulman's discussion of the operation console assigning an operational priority 
to an error reported by a network element does not teach or suggest at least the Appellants' 
claimed "the priority value assigned by the managed element." Indeed, there is no discussion in 
Dulman of how SNMP messages received by the network element are handled at the network 
element. 

Put simply, the prioritization in Dulman differs completely from the claimed invention. 
In particular, prioritization occurs in Dulman at an operations console which is more similar in 
function to the recited management station. In contrast, prioritization in the claimed invention is 
by the managed element . Dulman performs prioritization on SNMP objects related to error 
reports. These differ from the recited "network management requests"of the claimed invention. 
The SNMP objects received at the operations console in Dulman are not requests. Rather, they 
are of the nature of information that is typically returned in response to a request. 

The purpose for prioritization in Dulman is related to operational priority and display at 
the operations console. In contrast, prioritization in the claimed invention occurs such that 
"scheduling the network management request, bv the managed element dependent on the 
assigned priority value." Thus, it is clear that the Dulman reference differs substantially from the 
claimed invention as noted. 

Kjorsvik's mere discussion of data being displayed on screens of personal computers and 
identifying users of the personal computers based on a unique network identifier does not suggest 
the Appellants' claimed "user identifier in a network management wrapper." Kjorsvik does not 
even discuss a network management wrapper, network management request or even data transfer 
from the network server to the network PC. 

MPEP 2141.01(a) "Analogous and non-analogous art" states that to rely on a reference 
under 35 U.S.C. 103, such as in the present case, it must be analogous prior art, which Appellants 
urge Kjorsvik is not for reasons described further herein below. Further, MPEP 2141.01(a) states 
that 

[t]he Examiner must determine what is "analogous prior art" for the purpose of 
analyzing the obviousness of the subject matter at issue. "In order to rely on a 
reference as a basis for rejection of an applicant's invention, the reference must 
either be in the field of applicant's endeavor or, if not, be reasonably pertinent to 
the particular problem with which the inventor was concerned." In re Oetiker, 977 
F.2d 1443, 1446, 24 USPQ 2d 1443, 1445 (Fed.Cir. 1992). See also In re 
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Deminski, 796 F.2d 436, 230 USPQ 313 (Fed.Cir. 1986); In re Clay, 966 F.2d 
656, 659, 23USPQ 2d 1058, 1060-61 (Fed. Cir. 1992) ("a reference is reasonably 
pertinent if, even though it may be in a different field from that of the inventor's 
endeavor, it is one which, because of the subject matter with which it deals, 
logically would have commended itself to an inventor's attention in considering 
his problem.") 

"Where the general scope of a reference is outside the pertinent field of endeavor, the 
reference may be considered analogous art if the subject matter disclosed therein is relevant to 
the particular problem with which the inventor is involved." State Contracting & Eng'g Corp. v 
Condotte America Inc., 346 F.3d 1057, 1069, 68 USPQ 2d 1481, 1490 (Fed. Cir. 2003). 

In this case, the Kjorsvik reference is in a different, non-analogous field of endeavor 
because it involves a presentation system for individual PCs in a PC network, whereas the 
claimed invention relates to prioritizing network management requests by a managed element. 
The use of unique network identification in Kjorsvik is intended for identifying individual PC 
users at an administration module. In contrast, the user identifier in the claimed invention is used 
by a managed element to identify the user of an application from which a request was sent to the 
managed element. There is no communication of network management requests even occurring 
in Kjorsvik. Thus, one skilled in the art of network management would not look to the use of 
presentations (or screen savers) on personal computers to learn how to prioritize network 
requests. 

Thus, the Office has not established a prima facie case under 35 U.S.C. § 103 (a) because 
(1) there is no suggestion or motivation to combine reference teachings (Dulman and Kjorsvik) 
and (2) even if combined, Dulman and Kjorsvik do not teach or suggest all the claim limitations 
as discussed above. 

Furthermore, the failure of others to discuss assigning a priority value to the received 
network management request by the managed element is a secondary indication of 
non-obviousness. (Graham v. John Deere, 383 U.S. 1, 148 USPQ 459 (1966)). 

As base Claims 1,18, 27, 28, 29 and 30 recite novel subject matter, each of the dependent 
claims are also novel over Dulman and Kjorsvik, singly or in combination. The dependent 
claims also recite additional patentable limitations. Such limitations further distinguish the 
claimed invention and are not taught or suggested by Dulman and Kjorsvik, singly or in 
combination. 
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Claims 3, 20, and 33 recite that the priority value is added to "an authentication group 
comprising a plurality of users, in an authentication table." Dulman does not even discuss an 
authentication group or table in the network element. 

Claims 5, 21, 23, and 34 recite "determining the priority value by using the extracted user 
identifier to index the authentication table." Dulman does not even discuss how SNMP messages 
are processed by the network element. 

Claims 6 and 1 1 recite "selecting the order of execution of the network management 
request dependent on the determined priority value." As already discussed, Dulman does not 
even discuss processing of SNMP messages received by a network element. 

Claim 30 recites "the message is in the form of a Simple Network Management Request." 
Dulman does not discuss processing of Simple Network Management Requests by a managed 
element. 

Therefore, separately or in combination, Dulman and Kjorsvik do not teach or suggest the 
Appellants' claimed invention. Thus, none of the cited prior art alone or in combination teaches 
or suggests the Appellants' claimed invention directed to prioritizing a network management 
request. Accordingly, the present invention as now claimed is not believed to be anticipated or 
made obvious by the cited art. In view of the foregoing, removal of the rejection under 35 U.S.C. 
§ 103(a) and acceptance of Claims 1, 3, 5-9, 1 1-14, 18, 20-21, 23 and 27-34 are respectively 
requested in view of this Appeal and arguments set forth above. 



Respectfully submitted, 



HAMILTON, BROOK, SMITH & REYNOLDS, P.C. 



Timothy J. Meagher / 
Registration No. 39,302 
Telephone: (978) 341-0036 
Facsimile: (978)341-0136 




Concord, MA 01742-9133 

Date: iMl*^ 
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CLAIMS APPENDIX 

(Previously Presented) A method for prioritizing a network management request sent by a 
management station to a managed element, comprising the steps of: 

upon receiving a network management request, assigning a priority value to the 
received network management request , the priority value assigned by the managed element 
dependent upon a user identifier in a network management wrapper included in the request, 
the user identifier identifying the user of an application from which the request was sent; and 

scheduling the network management request, by the managed element dependent on 
the assigned priority value. 

(Canceled). 

(Previously Presented) The method as claimed in Claim 1 wherein the step of assigning 
further comprises the step of: 

adding a priority value to an authentication group comprising a plurality of users, in 
an authentication table. 

(Canceled). 

(Previously Presented) The method as claimed in Claim 3 wherein the step of scheduling 

further comprises the steps of: 

extracting a user identifier from the received network management request; and 
determining the priority value by using the extracted user identifier to index the 

authentication table. 

(Previously Presented) The method as claimed in Claim 5 wherein the step of scheduling 
further comprises the step of: 

selecting the order of execution of the network management request dependent on 
the determined priority value. 
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7. (Previously Presented) The method as claimed in Claim 6 wherein the step of selecting 
further comprises the step of: 

preempting the currently executing task if the determined value for the management 
request is higher than the currently executing task. 

8. (Previously Presented) The method as claimed in Claim 6 wherein the step of selecting 
further comprises the step of: 

adding the management request to the end of a request queue if the determined 
priority is lower than the priority of the tasks in the request queue. 

9. (Previously Presented) The method as claimed in Claim 6 wherein the step of selecting 
further comprises the step of: 

adding the management request to the front of a request queue if the determined 
priority is higher than the priority of the tasks in the request queue. 



10. (Canceled). 



1 1 . (Previously Presented) The method as claimed in Claim 3 wherein the step of scheduling 
further comprises the step of: 

selecting the order of execution of the network management request dependent on 
the determined priority value. 

12. (Previously Presented) The method as claimed in Claim 1 1 wherein the step of selecting 
further comprises the step of: 

preempting a currently executing task if the determined value for the management 
request is higher than the currently executing task 
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13. (Previously Presented) The method as claimed in Claim 1 1 wherein the step of selecting 
further comprises the step of: 

adding the management request to the bottom of a request queue if the determined 
priority is lower than the priority of the tasks in the request queue. 

14. (Previously Presented) The method as claimed in Claim 1 1 wherein the step of selecting 
further comprises the step of: 

adding the management request to the top of a request queue if the determined 
priority is higher than the priority of the tasks in the request queue. 

15-17. (Canceled). 

18. (Previously Presented) An apparatus for prioritizing a network management request sent by 
a management station to a managed element, comprising: 

a priority assignment routine which upon receiving a network management request 
assigns a priority value to the received network management request, the priority value 
assigned in the managed element dependent upon a user identifier in a network management 
header included in the request, the user identifier identifying the user of an application from 
which the request was sent; and 

a network management request routine which schedules the network management 
request in the managed element dependent on the assigned priority value. 

19. (Canceled). 

20. (Previously Presented) The apparatus as claimed in Claim 1 8 wherein the priority 
assignment routine further comprises: 

a priority value assignment routine which adds a priority value to an authentication 
group comprising a plurality of users, in an authentication table. 
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(Previously Presented) The apparatus as claimed in Claim 20 wherein the network 
management routine further comprises: 

a user identification extraction routine which extracts a user identifier from the 
network management request; and 

a priority value extraction routine which determines the priority value by using the 
extracted user identifier to index the authentication table. 

22. (Canceled). 

23. (Previously Presented) The apparatus as claimed in Claim 18 wherein the network 
management routine further comprises: 

a source identification extraction routine which extracts the user identifier from the 
network management request; and 

a priority value determination routine which determines the priority value using the 
extracted user identifier to index the source identification table. 

24 - 26.(Canceled). 

27. (Previously Presented) An apparatus for prioritizing a network management request sent by 
a management station to a managed element, comprising: 
a priority assignment routine; 
a network management request scheduler; 

upon receiving a network management request, means, within the priority 
assignment routine, for assigning a priority value to the received network management 
request, the priority value assigned in the managed element dependent upon a user identifier 
in a network management wrapper included in the network management request, the user 
identifier identifying the user of an application from which the request was sent; and 

means, within the network management request scheduler, for scheduling the 
network management request in the managed element dependent on the assigned priority 
value. 
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28. (Previously Presented) A computer program product for prioritizing a network management 
request sent by a management station to a managed element, the computer program product 
comprising a computer usable medium having computer readable code thereon, including 
program code which: 

upon receiving a network management request, assigns a priority value to the 
received network management request, the priority value assigned by the managed element 
dependent upon a user identifier in a network management header included in the request, 
the user identifier identifying the user of the application from which the request was sent; 
and 

schedules the network management request in the managed element dependent on 
the assigned priority value. 

29. (Previously Presented) A method for prioritizing a message requesting information stored in 
a managed element, the message being sent by a management station to the managed 
element, comprising the steps of: 

upon receiving a network management request, assigning a priority value to the 
received message, the priority value assigned by the managed element dependent upon a 
user identifier in a network management wrapper included in the request, the user identifier 
identifying the user of an application from which the request was sent; and 

scheduling the message, by the managed element dependent on the assigned priority 

value. 



30. 



(Previously Presented) The method of Claim 29 wherein the message is in the form of a 
Simple Network Management Request. 
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3 1 . (Previously Presented) A method for prioritizing a Simple Network Management Protocol 
message sent by a management station to the managed element, comprising the steps of: 

upon receiving a network management request, assigning a priority value to the 
received Simple Network Management Protocol message, the priority assigned by the 
managed element dependent upon a user identifier in a network management wrapper 
included in the message, the user identifier identifying the user of an application from which 
the message was sent; and 

scheduling the message, by the managed element dependent on the assigned priority 

value. 

32. (Previously Presented) A method for prioritizing a network management request sent by a 
management station to a managed element, comprising the steps of: 

upon receiving a network management request, assigning a priority value to the 
received network management request, the priority assigned by the managed element 
dependent upon a source identifier in a network management wrapper included in the 
request, the source identifier identifying the source of an application from which the request 
was sent; and 

scheduling the network management request, by the managed element dependent on 
the assigned priority value. 

33. (Previously Presented) The method as claimed in Claim 32 wherein the step of assigning 
further comprises the step of: 

adding a priority value to the source identifier in a source identification table. 

34. (Previously Presented) The method as claimed in Claim 33 wherein the step of scheduling 
further comprises the step of: 

extracting the source identifier from the network management request; and 
determining the priority value by using the extracted source identifier to index the 
source identification table. 
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